Is there a good way from a writing perspective to parameterize these statistics? I bring this up because any plugin can create and name its own thread pools, which are added to the statistics output automatically if it's the correct type. The stats mean the same thing across every threadpool that can be returned so it should cut down on reading effort, as well as trying to maintain this list for every thread pool we add.

I think we could do something like thread_pool.<thread_pool_name>.threads. We did something similar in the ingest section:
https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-nodes-stats.html#cluster-nodes-stats-api-response-body-ingest

I was debating this initially, but I decided to go with the current format because users might be searching for a specific thread pool name. However, I wasn't aware that this API would also pick up thread pools from plugins, which makes that direction kind of moot.

Updated with 00ae054.

After looking at the preview, I decided against adding a default list and just letting the <thread_pool_name> placeholder stand as-is.

Also updated the ingest section to use snake_case.

...users might be searching for a specific thread pool name

You could also potentially add the default thread pools names to the reference, but I think that sort of information is probably better documented elsewhere and linked to. Different thread pools often have a wide array of uses, which sometimes don't make sense without some decent explanation. It feels like it might be a bit much for a reference section.